Remove ambiguity for UNSPECIFIED UPayloadFormat #247
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Previously (version 1.3.6 and earlier of the specification) we did not have an enum for the payload format (it was a string) and sending the string was costly to the cloud even though we always knew it was WRAPPED_IN_ANY. To avoid sending the payload format we omitted the attribute and then "assumed" that if it was not present it would be WRAPPED_IN_ANY. Now that we have an enum defined, it is better to remove the ambiguity of this attribute and make it explicit, this means that if someone sets it to UNSPECIFIED it really means unspecified (we don't know or are not setting it to anything). Additionally, for SOME/IP there is no way to pass this attribute (UPayloadFormat) so we have to set UPayloadFormat as UNSPECIFIED and then leave it up to the client to know the format from the source. eclipse-uprotocol#237
sophokles73
requested changes
Nov 8, 2024
There was a problem hiding this comment.
Making this change will also require a change to the corresponding specitem revision in the uattributes/umessage specification where we define that the payload format should be assumed to be WRAPPED_IN_ANY if not specified. This will make sure that OFT discovers the discrepancy between spec and implementation...
Co-authored-by: Kai Hudalla <[email protected]>
There is no OFT requirement for this in upayload.adoc or in uattributes.adoc, it will need to be added on a subsequent PR |
sophokles73
added
the
breaking change
sophokles73
approved these changes
Nov 11, 2024
sophokles73
added a commit
to SoftwareDefinedVehicle/uprotocol-spec-fork
that referenced
this pull request
Nov 11, 2024
This is a follow up of eclipse-uprotocol#247
sophokles73
added a commit
to SoftwareDefinedVehicle/uprotocol-spec-fork
that referenced
this pull request
Nov 11, 2024
This is a follow up of eclipse-uprotocol#247
stevenhartley
pushed a commit
that referenced
this pull request
Nov 25, 2024
* Support UNSPECIFIED payload format in CloudEvents mapping This is a follow up of #247 * Change the type name of uProtocol messages The names defined for the different uProtocol message types have been changed to allow distinguishing between existing CloudEvents being exchanged by legacy systems using a predecessor of Eclipse uProtocol and CloudEvents conforming to the mapping rules defined in the uProtocol specification.
|
done |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Previously (version 1.3.6 and earlier of the specification) we did not have an enum for the payload format (it was a string) and sending the string was costly to the cloud even though we always knew it was WRAPPED_IN_ANY. To avoid sending the payload format we omitted the attribute and then "assumed" that if it was not present it would be WRAPPED_IN_ANY. Now that we have an enum defined, it is better to remove the ambiguity of this attribute and make it explicit, this means that if someone sets it to UNSPECIFIED it really means unspecified (we don't know or are not setting it to anything). Additionally, for SOME/IP there is no way to pass this attribute (UPayloadFormat) so we have to set UPayloadFormat as UNSPECIFIED and then leave it up to the client to know the format from the source.
#237